(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 




(12) 



01) EP 0 314 596 B1 

EUROPEAN PATENT SPECIFICATION 



(45) Date of publication and mentbn 
of the grant of the patent: 
23.04.1997 Bulletin 1997/17 

(21) Application number: 88480035.0 

(22) Date of filing: 13.09.1988 



(51) mtciA G06F 17/20, G06F 17/60, 
G06F 17/21 



(54) Automated interface to project management tool 

Automatisierte Schnittstelle fur Projektleitungswerkzeug 
Interface d un outil de gestion de projet 



(84) Designated Contracting States: 
DE FR GB IT 

(30) Priority: 28.10.1987 US 115073 

(43) Date of publication of application: 
03.05.1989 Bulletin 1989/18 

(73) Proprietor International Business Machines 
Corporation 

Armonk, N.Y. 10504 (US) 

(72) Inventors: 

• Ferriter, Kate M, 
Atlanta, GA 30339 (US) 

• Math Is, Robert B. 
Marietta, GA 30067 (US) 

(74) Representative: Tubiana, Max 
Compagnie IBM France 
Departement de Propriete Intellectuelle 
06610 La Gaude (FR) 



(56) References cited: 
WO-A-85/02699 



US-A-4 459663 



m 

to 
o> 
in 

^ , 

CO 

o 



• IEEE 1985 COMPINT - COMPUTER AIDED 
TECHNOLOGIES, Montreal, Quebec, 9th - 13th 
September 1985, pages 441-446; F. VERNADAT 
et al.: "CAD/CAM databases at NRC: from 
manufacturing cell database systems to 
engineering information systems" 

• EXPERT DATABASE SYSTEMS, PROCEEDINGS 
FROM THE FIRST INTERNATIONAL 
WORKSHOP, 24th - 27th October 1984, pages 
423-440, editor Larry Kershberg, US; S.J. 
CAMMARATA et al.: "An interactive data 
dictionary facility for CAD/CAM data bases" 

• CONTROL ENGINEERING, April 1971, pages 
61-64; C.A. RENOUARD: "A computerized 
inventory model for production control" 



Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give 
notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in 

a u/n'ttoo roacnnoH ctafomont It chall nnt ho HoomoH tn hawo hoon fi loH until tho nrw-icttirMn fao hac Kaon nairl /Art 



1 



EP 0 314 596 B1 



2 



Description 

BACKGROUND OF THE INVENTION 

Field of the invention 

The present invention generally relates to a compu- 
ter based project management system and, more par- 
ticularly, to a system which automatically interfaces a 
project management tool to a conceptual design tool to 
provide an integrated approach to hardware product de- 
sign. The conceptual design tool uses a top-down func- 
tional approach to product design which involves creat- 
ing and exploiting a hierarchical tree view of the product 
structure early in the design process. The invention pro- 
vided an interface for the detailed information gathered 
from the user and relational database of the conceptual 
design tool for early manufacturing involvement as well 
as bill of material and feasibility cost estimating to a com- 
puterized project management toot. 

Description of the Prior Art 

The process of designing, developing and manu- 
facturing a new product, or making major changes to 
existing products, presents many challenges to product 
managers and engineers to bring the product to market 
for the least cost, within schedule while maintaining 
product quality. In today's highly competitive industries, 
product managers and engineers require information to 
address many problems that arise because of the com- 
plexity of new products and the complexity of world-wide 
production and the changing nature of competition. Be- 
cause new products need to be brought to market in a 
very short time period to meet the competition, the tra- 
ditional learning curve formerly associated with product 
development has disappeared, creating the need to bet- 
ter control product release and determine cost impacts 
of designs early in the design process. 

To meet these needs, many companies are realiz- 
ing that. the conventional product design process is not 
satisfactory. They require early involvement of manufac- 
turing engineering, cost engineering, logistics planning, 
procurement, manufacturing and service/support with 
the design effort. In addition, they require planning and 
control of product data through design, release and 
manufacturing. 

Project Management, as a modern management 
tool, has its origins in the early part of this century when 
Henry L. Gantt, while working for the government during 
World War I, developed his now famous visual aid for 
work control. The Gantt chart is a graphic representation 
of a project schedule that shows each task as a bar hav- 
ing a length proportional to the duration of the task. Later 
during the 1950s, Dr. John Presper Mauchley, a co-in- 
ventor of the EDVAC at the University of Pennsylvania, 
developed the Critical Path Method (CPM) which was 
further developed by Willard Frazer, a consultant on the 



Polaris submarine project. Frazer*s contribution was 
called Program Evaluation and Review Technique 
(PERT). A PERT chart is one that resembles a How chart 
showing predecessor and successor tasks of a project 
& and the critical path. 

PERT/CPM models are known and have been used 
for many years by many large corporations for project 
management. Such project management tools were first 
implemented on main frame computers and then on mini 
10 computers, equipment which was readily available to 
large corporations but not to small corporations and 
firms. More recently, various project management soft- 
ware products have been developed for micro or so- 
called persona] computers. An example of a project 
is management tool which was originally written as a main- 
frame program and later rewritten as a personal com- 
puter program is Plantrac , published by Computerize, 
Inc. This program was originally written in England for 
the construction industry and later imported to the U.S. 
A. The first project management tool written specifically 
for the personal computer was called the Harvard 
Project Manager , now published by Software Publishing 
Corp. There are now over one hundred project manager 
applications written for personal computers. These have 
made computer based project management tools more 
economically accessible to small corporations and 
firms, but their application requires some degree of so- 
phistication on the part of the user. As a result, many 
small corporations and firms still use manual methods 
of project management, often relying on an expediter to 
stay one step ahead in scheduling supplies and work on 
a day to day basis. 

Rupert A. Schmidtberg and Mark A. Yerry in an ar- 
ticle entitled "Designing Complex Assemblies Using the 
Top-Down Approach* published in Autofact 1986 Pro- 
ceedings , at pages 9-31 to 9-43, describe a design ap- 
proach where the engineer first creates the top-most as- 
sembly and works downward, filling in details of the sub- 
ordinate subassemblies and parts. In this approach, a 
hierarchical representation of the design object is built 
and refined. As a design concept is refined, design con- 
straints are communicated down the hierarchy. Evalua- 
tion of the design concept at each level of refinement 
may cause feedback to be passed up the hierarchy in 
the form of recommendations for design changes or re- 
quests to relax some design constraints. 

This top-down design approach has significant ad- 
vantages over the traditional approach to design of a 
new product. The Schmidtberg and Yerry implementa- 
tion, however, is in the environment of a CAD/CAM sys- 
tem which assumes a high degree of computer design 
sophistication on the part of the user. What is needed is 
a simpler to use system which takes advantage of the 
top-down design approach and which then provides an 
interface with a project management tool to fully inte- 
grate the design and production of new hardware prod- 
ucts. 

In the prior art, have been disclosed systems to im- 
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prove databases for the CAP/CAD environment: this is 
the case for IEEE 1985 COMPINT - Computer Aided 
Technologies. Montreal, Quebec, 9th to 1 3th September 
1985, p.441 -446, by RVemadat et al. ('CAD/CAM data- 
bases at NRC: from manufacturing cell database sys- $ 
terns to engineering information systems', or EXPERT 
DATABASE SYSTEMS, PROCEEDINGS FROM THE 
FIRST INTERNATIONAL WORKSHOP, 24th to 27th 
October 1984, p.423-440, ed.Larry Kershberg, US, by 
S. J.Cammarata et al. fan interactive data dictionary fa* 10 
cility for CAD/CAM data bases'). 

This document discloses a relational database sys- 
tem DBS/R for adapting Computer Aided Manufacturing 
(CAM) databases to Flexible Manufacturing Systems 
(FMS). Characteristics of such CAM databases are pro- 1& 
vided under 'CAM 1 database requirements" and those 
of FMS under 'an FMS logical database". In order to 
make both those characteristics compatible, a tool DBS/ 
R is required. Though this document deals with the 
same problem as the subject invention, it does not 20 
solves it in the same way. As a matter of fact the solution 
according to the present invention results in an easy to 
use interactive system which implement a top-down 
functional approach to hardware product design by au- 
tomatically, within the same computing machine, input- 25 
ting the information gathered from the user to a project 
management tool. 

US patent 4,459,663 to Dye describes a system for 
automatic control of the manufacturing of end products 
and their components. It involves manipulating invento- 30 
ry and bill-of-material files, and actual or planned cus- 
tomers orders so as to as to generate work orders for 
the manufactured components necessary to fill the cus- 
tomers orders. 

3S 

SUMMARY OF THE INVENTION 

It is therefore a general object of the present inven- 
tion, as claimed, to provide an easy to use system which 
implements a top-down functional approach to hard- *Q 
ware product design and then automatically inputs the 
information gathered from the user to a project manage- 
ment tool. 

It is a more specific object of the invention to provide 
an interface which inputs the detail information gathered 
using a conceptual design tool as an input to a project 
management tool. 

According to the invention, a sketch sheet approach 
on a computer display is used to enter the functional de- 
sign of a product. The user needs to key in only part so 
descriptions, and the system automatically draws a hi- 
erarchical tree structure on the computer display. The 
user is then prompted to consider, part by part, all of the 
parts in the product. A series of menus pop-up and guide 
the user through manufacturing planning for the part. ss 

The process begins by producing a functional 
sketch of the product design. This sketch is in the form 
of a hierarchical tree structure, thereby encouraging the 



top-down design approach. The system queries the us- 
er for component parts of the product, and as the query 
process progresses, the tree structure is created on the 
computer screen for the user to view. 

Behind each elements, or Item, in the functional hi- 
erarchy of the product, associated manufacturing infor- 
mation is gathered. This manufacturing detail is used for 
product release planning and scheduling, and manufac- 
turing planning, as well as for feasibility level cost esti- 
mating. The user has the option at any time during the 
design process to deal with the proposed product or 
product components at a high level or at a very detailed 
level. At any level, manufacturing details which are not 
know by the user can be defaulted from a database us- 
ing the known item attributes. 

The product designer is aided in implementing early 
manufacturing involvement, or the integration of the de- 
sign process with manufacturing and other production- 
related concerns. The designer is prompted to enter 
manufacturing data for each item in the product struc- 
ture, thus introducing a third dimension to the hierarchi- 
cal tree structure. This third dimension serves several 
purposes. The manufacturing data can be manipulated 
to produce needed estimates and schedules for the de- 
signer. The manufacturing data of interest falls under 
four categories: (1 ) information which assists in planning 
the manufacture of the product, (2) information which 
assists in producing a cost estimate of the product, (3) 
information which assists in generating a product re- 
leases schedule, and (4) information which will assist a 
CAD/CAM designer in locating similar items. In the 
fourth instance, the designer then has the option to use 
the similar design, avoiding another design effort, or to 
use the existing design as a template to modify or for 
other guidance in preparing the new design. 

The hierarchical approach implemented by the in- 
vention provides a convenient interface to product cost- 
ing, as early cost estimates will consider only the very 
high level assemblies and very little detail. As the re- 
lease plan reaches completion, however, much more 
detail is available and the product cost estimate will roll 
up the more detailed tree structure to provide a more 
precise estimate. Cost estimates at the very early de- 
velopment phase of the product help determine product 
feasibility as well as to direct engineering effort at the 
most significant portions of the design. 

The manufacturing detail information gathered us- 
ing the conceptual design tool is automatically input to 
a project management tool. The automatic transfer of 
information required to generate a release schedule is 
a major usability and productivity enhancement over ex- 
isting semi-manual project management systems. The 
process utilizes available information, knowledge and 
interrelationships previously gathered through other re- 
quired phases of planning the product release plus user 
interactivity to produce a product release activity se- 
quence and schedule. No direct user interface to the 
project management tool is required, since all tasks and 
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activity times have been gathered by the conceptual de- 
sign tool in defining the product structure. The only ad- 
ditional information which the user needs to supply is 
the available capacity of each resource. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and ad- 
vantages of the invention will be better appreciated from 
the following detailed description of a preferred embod- 
iment of the invention with reference to the drawings, in 
which : 

Figure 1 is a system block diagram showing the 
functional requirements for implementing the auto- 
mated bill of material according to the invention; 
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Figure 2 is a pictorial representation of a hierarchi- 
cal tree structure showing the functional represen- 
tation of the components of a new product; 20 



11 expanded to three levels of detail in the tree 
structure; 

Figure 1 3 is a screen showing a page of the indent- 
ed bill of materials created from the examples 
shown in Figures 11 and 12; 

Figures 14 A, 14B and 14C, taken together, are a 
flow chart of the automated interface to the project 
management tool according to the present inven- 
tion; and 

Figures 15A, 15B, 15C, 15Dand 15E, taken togeth- 
er, are a flow chart of the process of formatting files 
of data gathered by the conceptual design tool for 
the project management tool and invoked by the in- 
terface shown in Figure 14A. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT OF THE INVENTION 



Figure 3 is a table illustrating the organization of the 
database for the hierarchical tree structure shown 
in Figure 2; 

Figure 4 is a generalized illustration of an indented 
bill of material produced by the invention from the 
relational database table shown in Figure 3; 

Figure 5 is a screen illustrating the computer display 
of a hierarchical tree structure generated by the sys- 
tem for a planned product under design; 

Figure 6 is a screen illustrating the computer display 
of early manufacturing involvement data for one 
component of the structure shown in Figure 5; 

Figure 7 is a screen illustrating the computer display 
of early manufacturing involvement data for one 
component with default data entered by the system; 

Figure 8 is a flow chart showing the logic of the con- 
ceptual design tool implemented in software; 

Figure 9 is a flow chart showing the logic of the que- 
ry session during which the hierarchical tree and ta- 
ble of Figures 2 and 3, respectively, are built in the 
database; 

Figure 10 is a flow chart showing the logic of the 
generation of the indented bill of material shown in 
Figure 4 using the table in the database; 

Figure 1 1 is a screen showing a specific example of 
two levels of detail in a tree structure for a lawnmow- 
er handle using the subject invention; 

Figure 1 2 is a screen showing the example of Figure 



Referring now to the drawings, and more particular- 
ly to Figure 1 , there is shown in functional block diagram 
an automated bill of material system. The key parts of 

25 this system are the database 1 0 and the query system 
12. The database 10 could be any of several products 
currently available, but for purposes of the preferred em- 
bodiment, IBM's DATABASE 2 (DB2) is used. DB2 is a 
relational data base management system, but it will be 

30 understood by those skilled in the art that other data bas- 
es, including hierarchical data bases, could be used. 
The query system 12 could be an expert system, but for 
purposes of the preferred embodiment. IBM's Restruc- 
tured Extended Executor (REXX) language is used. 

55 General information on IBM's DB2 can be had with ref- 
erence to publication GC26-4073-2 published by IBM 
Corp. A description of the REXX language is provided 
in Virtual Machine/Systems Product, System Product 
Interpreter User's Guide . Release 4, publication 

40 SC24-5238-2 published by IBM Corp. 

The user 14 is first queried on the functional product 
structure by the query system 1 2, and in response to the 
user input, the database 10 captures the structure in a 
table. The query session begins by prompting the user 

45 to input the name of the product. The product might be 
a new lawnmower, for example, and the user would sim- 
ply type in "LAWNMOWER 1 . Then the query system 
asks the user to list the major components of the prod- 
uct. In the case of the lawnmower, this might be a frame 

so assembly, an engine, a bagging assembly, and a handle 
and control assembly. These would be individually en- 
tered by the user in response to a prompt to enter the 
next component or indicate that there are no more major 
components by entering •END". Once the major com- 

ss ponents have been entered by the user, the user enters 
"END" causing the query session to then examine the 
subcomponents of the major components that have 
been entered. For example, the query system 12 would 
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prompt the user 1 4 to enter the components of the frame 
assembly. These components might be engine deck and 
wheels. Again, when all the subcomponents for the 
frame assembly have been entered, the user enters 
"END', causing the query system to next prompt the us- 
er to enter the components of the engine. In this case, 
a complete engine assembly might be procured from an 
outside source so that there are no components to be 
listed by the user, so the user simply enters "END*. The 
process continues until the user has entered all the com- 
ponents of the new product to a level of detail desired. 

As the query session progresses, the components 
entered by the user 14 are captured in a table by the 
relational database 1 0 and a functional hierarchical tree 
of the structure 16 is generated on a computer screen. 
A generalized example of this tree structure is shown in 
Figure 2 of the drawings. If a subassembly appears 
more than one time in a product, the subassembly also 
appears multiple times in the tree. In this example, the 
tree structure has three levels. It may have as few as 
two levels and, within practical limits, an indefinite 
number of levels depending on the product and the level 
of detail required to define that product. In a specific em- 
bodiment of the invention, up to thirty levels of the tree 
structure are allowed. Experience indicated that this is 
sufficient for all but the most complex of products. For 
the example of a new lawnmower, block 1 in Figure 2 
would contain the legend "LAWNMOWER". This block 
would be generated immediately upon the entry of the 
word "LAWNMOWER" by the user 14. Then, as the user 
enters the names of the major components of the lawn- 
mower, block 2 would be generated with the legend 
"FRAME ASSEMBLY", block 3 would be generated with 
the legend "ENGINE", block 4 would be generated with 
the legend "BAGGING ASSEMBLY", and block 5 would 
be generated with the legend "HANDLE AND CON- 
TROL ASSEMBLY". As these blocks are generated, 
lines connecting them to block 1 are also generated. 
Then in the next level, block 6 with the legend "ENGINE 
DECK" is generated followed by block 7 with the legend 
"WHEELS", again with lines connecting these blocks to 
block 2. Since the engine is being purchased as a com- 
plete assembly and no subcomponents were entered by 
the user, there is no block under block 3. Blocks 8, 9 and 
10 are then generated as the user enters subcomponent 
data in response to the query session. 

The database 10 captures the component informa- 
tion from the user input in a table having the form shown 
in Figure 3. Comparing this table to the hierarchical 
three of Figure 2, it will be observed that under the head- 
ing "ITEM" the numeral 1 is listed four times with the 
numerals 2, 3, 4, and 5 immediately to the right. This is 
followed by the numeral 2 listed twice with the numerals 
6 and 7 immediately to the right. Thus, the table shown 
in Figure 3 directly describes the hierarchical three 
structure from which the graphical representation illus- 
trated in Figure 2 is generated for display on the com- 
puter screen. The user views this tree structure and can 



check it for correctness as it is generated and after the 
product structure is established by the end of the query 
session. 

Referring back to Figure 1, once the product struc- 

5 ture is established, the next operation it to build and in- 
dented bill of material 18. For the product generally rep- 
resented by the hierarchical tree structure shown in Fig- 
ure 2 and the relational database table shown in Figure 
3, the indented bill of material would have the general 

io form shown in Figure 4. Those skilled in the art will rec- 
ognize that Figure 3 shows the logical storage of the 
product data structure and Figures 2 and 4 show two, 
alternative representations of the data. This bill of ma- 
terial is built by accessing the database table for the 

is product. The table is accessed by item number. In the 
top level, item 1 is not indented. The second level items 
2 ( 3, 4, and 5 are indented one space. The third level 
items 6, 7, 8, 9, and 10 are each indented two spaces, 
and so on. The application code follows the item hierar- 

20 chy as follows: Item 1 appears on the top line. Item 2 
appears on the second line. Then the database is 
searched for item 2 antecedents. Items 6 and 7 would 
be found. Item 6 would then appear on the third line. The 
database is then searched for item 6 antecedents. In 

25 this example, none would be found, and item 7 would 
then appear on the fourth line. Again, the database is 
searched for item 7 antecedents, but again non would 
be found, and item 3 would appear on the fifth line. The 
remaining items are similarly processed until a complete 

30 bill of material is produced Figure 5 shows a concrete 
example of a hierarchical tree structure generated on 
the computer screen during the query process. While 
only two levels are shown, those skilled in the art will 
understand that, within practical limits, a plurality of lev- 

6 els may be generated depending on the product and the 
level of detail required to define that product. Also, de- 
pending on the capabilities of the display system being 
used, the hierarchical tree structure may be displayed 
on several successive screens as the level of detail 

40 progresses. To do product costing, a product structure 
is first created using the hierarchical tree structure. For 
each item in the product structure, the user must enter 
known manufacturing information. From this informa- 
tion, cost estimates can be drawn from the database 1 0. 

45 The user inputs a rough estimate on overall product as- 
sembly time in hours per unit, as well as a contingency 
factor, like 15%. The system decomposes the product 
structure into a parts list, which is the indented bill of 
materials. The quantity of each part as well as cost per 

50 part are pulled from the manufacturing information table 
in the relational database associated with each item. 
The cost estimating function then multiplies each part 
on the list by quantity of that part, then by cost of the 
part. The results for the parts list are added. The labor 

55 estimate is multiplied by the standard hourly labor and 
burden rate. The results of the parts list multiplication 
and the labor multiplication are added, and the result is 
output to the user. 
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Figure 7 shows a screen from a computer display 
which would appear when the user selects, for example, 
BATTERY as the object and chooses the action "DE- 
TAIL". The design engineer keys in known manufactur- 
ing data using this screen. In this example, the designer 
intended to use an "off the shelf battery to be purchased 
complete from Sears. There is one battery in the product 
structure, and its function is power unit. The user can 
then choose to have default values supplied from the 
relational database based on known item attributes. The 
user selects the action "DEFAULT 1 , and the screen 
shown in Figure 8 is displayed. The method by which 
the relational database can access these defaults is by 
accessing the table in which the user input data was 
captured du ring th e query session . More specif ica lly, th e 
attributes in the table are accessed by attribute numbers 
and these numbers, in turn, are used as an index to ac- 
cess the default attributes for the items, these values 
having been previously stored for similar parts in the da- 
tabase. The screen shown in Figure 7 displays the re- 
sultant default values, marked by an asterisk. The sys- 
tem has generated an item number, A000. From the po- 
sition of the item within the tree, the system has deter- 
mined that it is a Main Assembly. The full name of the 
vendor, Sears Roebuck, Inc., is inserted. The process 
by which the battery is incorporated into the product is 
assembly. Tooling lead time defaults to zero since the 
item is purchased complete off the shelf. The cost per 
battery, based on actuals, is 15.00. An item classifica- 
tion, or group technology classification is system gener- 
ated based on the gathered attributes, function, sourc- 
ing strategy and vendor. This item classification code 
can be used in many production planning functions, in- 
cluding scheduling and procurement. 

Referring now to Figure 8, there is shown a flow 
chart of the logic of the conceptual design tool imple- 
mented in software. One of ordinary skill in the art can 
write source code from this flow chart in any suitable 
computer language, such as BASIC, Pascal or C, for 
any desired computer system, such as the IBM Personal 
System (PS) computers which support those computer 
languages. 

The process begins by inputting the tunctional 
structure of the product as indicated by function block 
100. This is done during the query session as is de- 
scribed in more detail with respect to Figure 9. Once the 
functional structure of the product has been input and 
the hierarchical three structure has been generated to 
the current level of detail desired, the user is prompted 
to select an item in the structure in function block 102. 
When the user selects an item, the system provides a 
pop-up panel for manufacturing details in function block 
104. This pop-up panel allows the user to key in known 
manufacturing information in function block 106. When 
this information has been input by the user, the system 
generates an item number in function block 108. The 
system then allows the user to choose to access default 
information in function block 110. A test is made in de- 



cision bbck 11 2 to determine if the user has chosen to 
access default information. If not, a test is next made in 
decision block 114 to determine if there are more items 
for which manufacturing details are to be input. If so, 
s then the process loops back to function block 1 02. 

Assuming that the test in decision block 1 1 2 is pos- 
itive, that is, the user chooses to access default infor- 
mation, then in function block 116, the system accesses 
the default values in database 10 and inserts those val- 

10 ues. Then, in function block 118, the system generates 
an item classification code. The user is given the option 
of overriding any of the default data in function block 
120. A test is made in decision block 122 to determine 
if the user chooses to override any default data. If so, 

75 the system loops back to function block 106 which al- 
lows the user to key in known manufacturing data as a 
typeover of the previously inserted default data; other- 
wise, the system loops to function block 102 to select 
the next item in the functional structure of the product. 

20 Eventually, the test in decision block 114 will be nega- 
tive, and the process ends. 

Figure 9 shows in flow chart form the logic of the 
query system according to the invention. The program 
logic represented by Figure 9 is what builds the data- 

25 base represented by Figure 3. This flow chart in combi- 
nation with a dialog system, such as IBM's REXX lan- 
guage, and a database system, such as IBM's DB2, is 
sufficient for a programmer of ordinary skill in the art to 
write the required code to implement the query system. 

30 With specific reference to Figure 9, the process begins 
by setting €=1 at block 20, where I is the product or com- 
ponent level. Then, at function block 22 the user of the 
system is prompted for the product name. In the exam- 
ple given, the name would be TAWNMOWER". The 

35 system waits for a user input at decision block 24, and 
when the product name has been input, the system 
opens a file in the database with the product name and 
displays the product name on a computer screen in 
function block 26. In block 28, 1 is set to 1+1 indicating 

*o the next level of components, and the system then 
prompts the user in function block 30 for the compo- 
nents of the product at this level. Each time the user 
inputs a component as detected by decision block 32, 
the inputted component is stored in the data base for 

45 that level in function block 34, and the system displays 
the inputted component on the computer screen at a 
node of the tree structure in function block 36. The sys- 
tem will continue to prompt the user for components af- 
ter each component is entered by the user until the user 

so presses an END function key which signals an end to 
the list of components for this level. Thus, the system 
tests the user input in decision block 38 for the END 
function key input. If that key input is not detected, then 
the system waits for the next user input in decision block 

55 32, and when an input is received, the component is 
stored in the database table in function block 34 and so 
forth. 

Once all the components have been input by the 
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user for a given level as indicated by pressing the END 
function key, the system then determines in decision 
block 40 if the last component in the current level of com* 
ponents has been input by the user. If not, the next com- 
ponent in the current level is highlighted in the displayed 
tree structure, and the system loops back to function 
block 30 where the user is again prompted for compo- 
nents of this component. On the other hand, if the last 
component of the current level of components has been 
input by the user as detected in decision block 40, the 
system tests for a user input in decision block 44 to de- 
termine if components are to be entered for the next lev- 
el. This is accomplished by the user pressing a Y key or 
an N key when prompted for the next level. If the Y key 
is pressed indicating that the user now wants to input 
the next level of components, the system loops back to 
block 28 to index to the next level. If on the other hand, 
the N key is pressed indicating that the user does not at 
this time wish to input the next level of components or 
that there is no next tevel of components to enter, the 
query process ends. 

Turning nowto the flow chart of Figure 10, this figure 
shows how the intended bill of materials is automatically 
generated from the table in the database which was built 
during the query session. Again, this flow chart shows 
the logic of the automatic generation of the indented bill 
of materials, and any programmer skilled in the art with 
an understanding of database systems, such as the IBM 
DB2 database, can write code to implement the inven- 
tion from the logic of the flowchart. The process begins 
in Figure 10 by setting b1 and b0 in block 46, where I 
is the component level as before and i is the indentation 
of the bill of materials. Next, item 1 of level 1 is accessed 
in function block 48. In the example given, this item is 
the product name "LAWNMOWER". Item 1 is then print- 
ed in function block 50, and I and i are then indexed by 
adding 1 to each. A test is then made in decision block 
54 to determine if any level I is left in the tree. If so, the 
system accesses the next left-most item in the three of 
the current level in function block 56. The accessed item 
is then printed in function block 58 with indentation i. A 
search is then made of the data base in function block 
60 for antecedents. If any are found in decision block 
62, the system loops back to block 52 where the level 
and indentation are indexed by one. Otherwise, a test 
is made in decision block 64 to determine if the last item 
of the current level has been connected. If so, the level 
and the indentation are indexed backward in block 66 
by subtracting one from each. The process then returns 
to decision block 54 to continue the process of access- 
ing and printing items in order. When the test in decision 
block 54 becomes negative, that is there are no levels I 
left in the tree structure, the level and indentation are 
again indexed backward by subtracting one in block 68. 
A test is then made in decision block 70 to determine if 
the indentation i is less than or equal to zero. If not, the 
process loops back to decision block 45; otherwise, the 
indented bill of materials is complete and the process 



ends. 

Having described the logic of the system, the user 
interface of a further specific example will be illustrated 
by way of screen dumps. The first of these is shown in 
5 Figure 11 which shows the product "LAWNMOWER" 
and a first major component 'HANDLE* with two of its 
subcomponents "UPPER HANDLE - and "LOWER 
HANDLE" displayed in a simple tree structure. This tree 
represents three levels in terms of the logic illustrated 

10 by the flow charts of Figures 9 and 10. In Figure 12, the 
user has input the components of a fourth level for the 
subcomponent "UPPER HANDLE" From these two il- 
lustrations, it will be apparent the manner in which each 
component level is built by user input to the system. Fi- 

J£ nally, in Figure 13 the indented bill of materials for the 
handle assembly of the lawnmower is shown as it ap- 
pears on the computer screen. Note that the bill of ma- 
terial may be scrolled up or down by the cursor keys as 
indicated in order to display the complete bill of material 

20 as generated from the data base. 

From the foregoing, it will be appreciated that even 
the most unsophisticated computer users will be able to 
quickly produce a bill of material for a new product using 
the system according to the invention. The process will 

25 help to identify those components and subcomponents 
of the product which require more specification as to 
source or structure early in the design stage. 

The next stage in the process is to input the data 
gathered by the conceptual design tool to a project man- 
so agement tool. The preferred embodiment of the inven- 
tion provides and interface between the conceptual de- 
sign tool and the Management and Project Planning 
System (MAPPS) project management tool published 
by Mitchell Management Systems, Inc. This program in- 

35 eludes two utility programs called MAPPOUT and MAP- 
PIN. MAPPOUT enables the user to access network da- 
ta contained in MAPPS networks by taking the interlock- 
ing MAPPS network data files and by putting that infor- 
mation inlo ASCII format. The restructuring essentially 

40 unlocks the files, separates the MAPPS network data, 
and makes it accessible to create new report formats or 
to recombine it with data from other programs. MAPPIN 
allows the user to extract data from other programs and 
to incorporate it into MAPPS. MAPPIN is an interface 

45 that enables data from another program to be inserted 
directly into MAPPS network data files. 

While the MAPPS project management tool is used 
in the preferred embodiment of the invention and repre- 
sents the best mode of practicing the invention, those 

so skilled in the art will appreciate that other project man- 
agement tools with similar capability and function could 
be adapted for use in the practice of the invention. 

With the present invention, no direct user interface 
to the project management tool is required, since all 

ss tasks and activity times have been gathered by the con- 
ceptual design tool for each item in the product struc- 
ture. The only additional information which the user 
needs to supply is the available capacity of each re- 
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source. The information available from the conceptual 
design tool includes the technology required to produce 
the item, item type, item classification code, procure- 
ment source, lead time to design the item, lead time to 
simulate the time (if required), lead time to prototype the & 
item, lead time to provide tooling to make the item (if 
required), time to release the item from engineering to 
manufacturing, lead time to procure the item (if re- 
quired), time to transport the item from vendor (if re- 
quired), time to inspect the item (if required), and time io 
to retrieve the item (if required). 

Project management techn iques are used to sched- 
ule product release. The user submits a product struc- 
ture which also carries manufacturing detail for each 
item for a product release schedule. Items within the is 
structure for which there are missing lead times are 
highlighted, although missing lead times may be default- 
ed to standard default time if the user does not override. 
The user reviews the application profile, and restricted 
update of the release planning assumptions can be 20 
done. Using DEFINITION OF ITEM CRITICALITY func- 
tion, the user can modify the rules which determine 
whether an item is critical. Only critical items within the 
product structure are sent to the project management 
tool. Criticality factors include item cost, item procure- 2S 
ment and tooling lead times, and new technology fac- 
tors. Assumptions also include forward and backward 
project scheduling, and a project completion date if 
backward scheduling is chosen. Also necessary is a de- 
fault estimate for each of the following : 30 

Time unit of measure, either days or weeks. 

Design time for the average part in the assembly. 
Unusual design times are specified in the manufacturing 
detail. The number of designers as resources for the 
project is also required. 35 

Simulation time per part. The number of simulators 
available as resources for the product is also required. 
If the same people do both design and simulation, a pro- 
portional amount of resource should be allocated to both 
activities. 40 

Prototyping time per part. The number of prototyp- 
ing resources available for this product is required. If the 
same people do both design, prototyping and simula- 
tion, a proportional amount of resource should be allo- 
cated to each of the three activities. 45 

Default tooling time per part (if the user did not in- 
dicate a time within the manufacturing detail informa- 
tion, the default will be used rather than non information 
at all). If tooling resource can be capacitating, the 
number of tooling resources should be specified. so 

Default time to release an item from engineering to 
manufacturing. 

Default procurement time per part. 

Default transportation time per part. ss 

Default inspection time per part. 

Default retrieval from stores time per part. 



Default assembly time (the default time may be ze- 
ro, since assembly time typically is much smaller than 
any other time considerations). 

The amount of time the enterprise allots to perform 
engineering preanalysis for a product. 

The amount of time the enterprise allots to perform 
formal release for a product. 

Percent contingency to built into the plan. 

In addition, the holiday schedule of employees as- 
signed to the product must be verified. 

The product structure is decomposed into a part list 
by the system, as has already been described DEFINI- 
TION OF ITEM CRITICALITY function is invoked, and 
based on the user's chosen factors, the parts list is mod- 
ified. All manufacturing detail information on each part 
on the list is passed to this function. Items which are not 
critical are eliminated from the list using the DEFINI- 
TION OF ITEM CRITICALITY function. The system then 
invokes the RELEASE PROJECT MANAGEMENT 
function. The critical parts list and corresponding lead 
time information are passed to the project manager. 
Each part requires a certain zero or non-zero amount of 
unit time for design, simulation, prototyping, tooling, pro- 
curement, transportation, inspection, retrieval from 
stores, product preanalysis, and formal release. The 
RELEASE PLAN PROJECT MANAGEMENT function 
operates in either forward or backward scheduling 
mode. In forward scheduling mode, each item has a se- 
ries of time and resource consuming events associated 
with it. The user does not determine the first customer 
ship date for the product until the project manager has 
completed the release schedule. The project manager 
needs to select the longest lead time item, and schedule 
It first. Any resources consumed are subtracted from 
available resource. The project manager continues to 
select long lead time items, until all are scheduled. Re- 
sources will not be overallocated, as the first customer 
ship date will be pushed out for both time and resource 
reasons. Backward scheduling involves choosing the 
first customer ship date and working backward to fit all 
required activities in prior to that date. During this proc- 
ess, available resources may be overallocated. The 
project manager needs to highlight that fact to the user, 
but continue the scheduling process, as the user may 
be able to get additional resource if the need arises. 

A detailed product schedule by item is then pro- 
duced, for all critical items. The procedure described 
may be iterative with both product structuring and cost 
estimating. 

The user then needs to create engineering changes 
to implement the product release. That process begins 
with the detailed product schedule with release dates 
for each critical item within the product. The user re- 
quests engineering changes bundling and inputs the de- 
sired frequency for engineering change package releas- 
es. Frequencies would typically be one per month or two 
week periods. An engineering change number for each 
engineering change release is then generated by the 
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system. The system determines the release date for 
each item in the release schedule. These dates are 
grouped into the time periods as defined by the user. EC 
NUMBER ASSIGNMENT function is invoked to system 
generate an engineering change number for each engi- s 
neering change release required. 

With this briel introduction, reference is now made 
to Figures 14A, 14B and 14C which, taken together, 
form a flow chart of the automated interface to the 
project management tool. The logic depicted in this flow '<> 
chart is sufficient for a programmer of ordinary skill in 
the art to write source code in a high level language such 
as BASIC, Pascal or C to implement the invention. The 
process begins in Figure 14A where, in function block 
200, the conceptual design tool is used to build and is 
modify the product structure. This process was de- 
scribed with reference to Figure 9. Next, in function 
block 202, the conceptual design tool is used to input 
manufacturing details by item in the structure. This proc- 
ess was described with reference to Figures 6, 7 and 8. 20 
At this point, the user can request the generation of a 
release schedule, as indicated in function block 204. 

When the user requests the generation of a release 
schedule, the project management interface according 
to the present invention is invoked in function block 206. & 
The manner in which the data files generated by de con- 
ceptual design tool are formatted for the project man- 
agement tool is described in detail with reference to Fig- 
ures 15A to 15E. The user is next asked in decision 
block 208 whether forward or backward scheduling is 30 
desired. If forward scheduling is chosen by the user, the 
user is prompted to fill in the start date in block 210, but 
if backward scheduling is chosen, the user is prompted 
to fill in the first customer ship date in block 21 2. 

Control then goes to decision block 21 4 at the top 3S 
of Figure 14B where the user is given the option to up- 
date the application profile defaults. The profiled de- 
faults are automatically inserted by the system, and the 
user can elect to use the defaults or change them. If the 
user chooses to update the defaults, then in function 40 
block 216 the user can key in new values by typing over 
the those default values the user wants to update. The 
process then goes to decision block 218 where again 
the user is given the option of updating the system data, 
this time the definition of criticality. If the user chooses 
to update, then in function block 220 the user can key 
in new definitions by typing over those the user wants 
to update. 

At this point, the system selects items which fulfill 
criticality requirements in blocks 222, 223 and 224 to so 
produce a list of selected items in block 226. Those 
skilled in the art will appreciate that this sort of selection 
process is routinely accomplished with a database and, 
as previously mentioned, the preferred database is 
IBM's DB2. Next in blocks 228, 229 and 230 the lead ss 
times for each item in the list produced in block 226 are 
added to produce in block 232 at the top of Figure 14C 
a list of all items and associated lead times. 



Once the list produced in block 232 is produced, the 
system extracts additional lead times from the applica- 
tion profile in block 234 and these lead times are added 
for each item in block 236. Next, the system finds the 
longest lead time in the list in function block 238. All 
events with associated lead times are defined as activ- 
ities in function block 240, and the activities for the item 
are listed in function block 242. A determination is made 
in decision block 244 whether there are more items to 
process in the list. If there are, control loops back to func- 
tion block 238 where the next longest lead time item is 
found and so on. Once the last item has been proc- 
essed, the files are formatted for the project manage- 
ment tool in function block 246. 

The process of formatting the files for the project 
management tool, here the MAPPS project manage- 
ment tool, is shown in Figures 15A to 15E. The process 
begins in Figure 1 5A by calling a MAPPS network data 
file shell in function block 250. This is an empty data file 
with no activities or resources. Then, in function block 
252, the name of the project is printed in the file shell. 
This name is the conceptual design tool product name. 
A check is made in decision block 254 to determine if 
the name is valid and, if not, an error message is dis- 
played in block 256 before control returns to block 252. 
Assuming a valid name has been printed to the file, the 
header information for the file is printed in function block 
258. Checks of each of the numbers of activities, re- 
sources, connectors, and milestones are checked in 
function block 260, and if any fail as determined by de- 
cision block 261 , an error message is displayed before 
control returns to function block 260. 

Once the header information has been printed to 
the file, the next step in the process is to print the activ- 
ities file, as shown in block 264 at the top of Figure 1 5B. 
The data field option is set equal to APPEND in block 
266, and the process of printing activity numbers begins 
in block 268. Each activity number is followed by printing 
the activity details to the file in block 270. A logical check 
is made in block 271 before a determination is made in 
decision block 272 as to whether there are more activi- 
ties to be printed to the file. Next the resources file is 
printed to the file in block 274. The data field option is 
set equal to APPEND in block 276, and the process of 
printing resource sequence file number begins in block 
278. After each resource file number, the resource detail 
is printed to the file in block 280. A logical check is made 
in block 281 before a determination is made in decision 
block 282 as to whether there are more resources to be 
printed to the file. 

Next, at the top of Figure 15C, the time and cost 
Information is printed in function block 284. For each ac- 
tivity, the activity number is verified in block 286, and the 
time and cost detail is printed to the file in block 288. 
This process continues until a determination is made in 
decision block 289 that all activities have been proc- 
essed. 

The activity resource usage is then printed to the 
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file in function block 290. For each activity the activity 
number is again verified in block 292, and the activity, 
resource number and usage detail is printed to the file 
in block 294. This process continues until a determina- 
tion is made in decision block 295 that all activities have £ 
been processed. 

The activity milestones are printed to the file in func- 
tion block 296. in function block 298 at the top of Figure 
15D, the milestones are printed followed by the date in 
block 300. As this is done, the activity numbers are ver- 10 
ified in block 302. This process continues until all mile- 
stones have been processed as determined by decision 
block 303. 

The connector information is formatted next. In 
block 304 the activities for the several item numbers are i$ 
selected, and then in block 306 the activities are ordered 
according to date. The connector file is printed to the file 
in block 308. For each activity, the activity is printed in 
block 310 until all activities have been processed as de- 
termined by decision block 311. The from/to relation- 20 
ship, that is the connector information, is specified in 
block 312 until all items have been processed as deter- 
mined by decision block 314. 

Referring now to the top of Figure 15E, the various 
files which have been printed are copied into the 2$ 
MAPPS network data file shell using the MAPPSIN util- 
ity described above, as indicated by function block 31 6. 
Next, a project data file is submitted to the MAPPS 
project management tool in block 318. At this point, the 
MAPPS project management tool can be executed as so 
indicated by block 320. The modified project data file is 
returned in block 322. The MAPPSOUT utility can then 
be invoked in block 324 to create a MAPPSOUT file of 
the format previously described. In this format, the mod- 
ified project data file can be imported into the conceptual 3S 
design tool to update the project data, as indicated in 
block 325. 

The automatic transfer of information required to 
generate a release schedule is a major usability and pro- 
ductivity enhancement over existing semi-manual 40 
project management systems. It utilizes available infor- 
mation, knowledge and interrelationship previously 
gathered through other required phases of planning the 
product release plus user interactivity to produce a prod- 
uct release activity sequence and schedule. 45 



Claims 

1. A method allowing a user (14) to improve the man- so 
ufacturing process of a product, comprising the fol- 
lowing steps performed through a single data 
processing unit, including input means allowing 
said user to input data in said data processing unit, 
display means allowing said data processing unit to 55 
display data to said user, and a relational database 
(10) allowing said data processing unit tostore data: 



prompting (12, 100, 200) said user to input a 
list of assembly parts for said product, 

- displaying a structure (1 6) of said product under 
the form of hierarchical tree of said assembly 
parts, and storing said structure in said relation- 
al database, 

building an indented bill of material (18) from 
said structure for said product, and displaying 
said indented bill of material, and 

- prompting (104, 202) said user to input manu- 
facturing information associated with each of 
said assembly parts, including manufacturing 
lead time and activities, and storing said man- 
ufacturing information in said relational data- 
base, 

said method being characterized in that it further 
comprises the steps of: 

- prompting (214, 216, 218, 220) said user to in- 
put requirements for assembly parts to be crit- 
ical in the manufacturing process of said prod- 
uct, 

comparing said criticality requirements with 
said manufacturing information for each of said 
assembly parts, and selecting (222, 223, 224, 
226, 228, 229, 230, 232) from said relational 
database those assembly parts having associ- 
ated manufacturing information meeting said 
criticality requirements, 

- ordering (238, 240, 242, 244) said selected as- 
sembly parts according to their decreasing 
manufacturing lead time, and listing all of said 
ordered parts along with their respective asso- 
ciated manufacturing information, including 
manufacturing lead time and activities, in an in- 
put file to a tool, in said data processing unit, 
for management of the manufacturing process 
of said product. 

The method of claim 1, wherein said tool for man- 
agement of the manufacturing process of said prod- 
uct is a Management and Project Planning System 
(MAPPS). 



Patentanspruche 

1. Verfahren, das einem Benutzer (1 4) die Verbesse- 
rung des Fertigungsprozesses eines Produktes er- 
moglicht, das die fotgenden Schritte umfaGt, die von 
etner einzelnen Datenverarbeitungseinheit ausge- 
fuhrt werden, diefolgendes beinhaltet: Eingabemit- 
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tel. die dem Benutzer die Eingabe von Daten in die 
Datenverarbeitungseinheit ermoglichen, Anzeige- 
mittel, die es der Datenverarbeitungseinheit ermog- 
lichen, dem Benutzer Daten anzuzeigen, und etne 
relationale Datenbank (10), die der Datenverarbei- s 
tungseinheit die Speicherung von Daten ermog- 
licht: 

- Auffordem (12, 100, 200) des Benutzers zur 
Eingabe einer Montagestuckliste fur das Pro- 10 
dukt, 

Anzeigen einer Struktur (16) des Produktes in 
Form eines hierarchischen Baumes der Mon- 
lageteiie und Speichern der Struktur in der re- is 
lationalen Datenbank, 

Erstellen einer Strukturstuckliste (18) aus der 
Struktur fur das Produkt und Anzeigen der 
Strukturstuckliste, und 20 

Auffordem (104, 202) des Benutzers zur Einga- 
be von Fertigungsinformationen, die jedem der 
Montageteile zugeordnet sind, einschlieGlich 
der Fertigungsvorlaufzeit und der Fertigungs- 25 
vorgange, und Speichern der Fertigungsinfor- 
mationen in der retationalen Datenbank, 

wobei das Verfahren dadurch gekennzeichnet ist, 
daB es auflerdem die folgenden Schritte umfa&t: 30 

- Auffordem (214, 216, 218, 220) des Benutzers 
zur Eingabe des Bedarfs an Montageteilen, die 
im FertigungsprozeB des Produktes kritisch 
sind, 3S 

- Vergleichen des kritischen Bedarfs mit den Fer- 
tigungsinfonmationen fur jedesder Montagetei- 
le und Auswahlen (222, 223, 224, 226, 228, 
229, 230, 232) jener Montageteile aus der re- 40 
lationalen Datenbank, denen Fertigungsinfor- 
mationen entsprechend dem kritischen Bedarf 
zugeordnet sind, 

- Bestellen (238, 240, 242, 244) der ausgewahl- 
ten Montageteile gemaft ihrer abnehmenden 
Fertigungsvorlaufzeit und Auf listen aller best ell- 
ten Telle zusammen mit ihren jeweils zugeord- 
neten Fertigungsinformationen, einschlieGlich 
der Fertigungsvorlaufzeit und der Fertigungs- so 
vorgange, in einer Eingabedatei zu einem Hilfs- 
programm in der Datenverarbeitungseinheit zur 
Verwaltung des Fertigungsprozesses des Pro- 
duktes. 

55 

2. Verfahren von Anspruch 1, in dem das Hilfspro- 
gramm zur Verwaltung des Fertigungsprozesses 
des Produktes ein Verwaltungs- und Projektpla- 



nungssystem (MAPPS) ist. 



Revendlcatlons 

1. Proc6d6 permettant a un utilisateur (14) d'amSliorer 
le processus de fabrication d'un product, compre- 
nant les 6tapes suivantes r6alis6es par I'intermG- 
diaire d'une seule unite* de traitement de donnees, 
comprenant un moyen de saisie permettant audit 
utilisateur de saisir des donn£es dans ladite unite 
de traitement de donn6es, un moyen d'affichage 
permettant a ladite unite de traitement de donnees 
d'afficher des donn6es pour ledit utilisateur, et une 
base de donn6es relationnelle (10) permettant a la- 
dite units de traitement de donnees de mSmoriser 
des donnees : 

- demander (12, 100, 200) audit utilisateur de 
saisir une liste de pieces de montage dudit pro- 
duit, 

afficher une structure (16) dudit produit sous la 
forme d'un arbre hi6rarchique desdites pieces 
de montage, et mSmoriser ladite structure dans 
ladite base de donnees relationnelle, 

construire une fiche de materiel indented (18) 
a parti r de ladite structure pour ledit produit, et 
afficher ladite fiche de materiel indented, et 

demander (1 04, 202) audit uti-lisateur de saisir 
des informations de fabrication associSes a 
chacune desdites pieces de montage, compre- 
nant le temps de planification de la fabrication 
et des activites, et m6moriser lesdites informa- 
tions de fabrication dans ladite base de don- 
n6es relationnelle, 

ledit proc6d6 6tant caract6ris6 en ce qu'il comprend 
en outre les Stapes consistant a : 

- demander (214, 216, 218, 220) audit utilisateur 
de saisir les exigences concernant les pieces 
de montage qui seront critiques dans le proces- 
sus de fabrication dudit produit, 

comparer lesdites exigences critiques auxdites 
informations de fabrication pour chacune des- 
dites pieces de montage, et sdlectionner (222, 
223. 224, 226, 228, 229, 230, 232) a partir de 
ladite base de donnees relationnelle, les pieces 
de montage particulieres presentant des infor- 
mations de fabrication associees qui satisfont 
lesdites exigences critiques, 

- ordonner (238, 240, 242, 244) lesdites pieces 
de montage sdlectionndes conformSment a 
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leur temps de planification de fabrication d6- 
croissant, et 6tablir la liste de toutes lesdites 
pieces ordonndes en meme temps que leurs in- 
formations de fabrication associ6es respecti- 
ves, comprenant les temps de planification de $ 
la fabrication et les activites, dans un fichier 
d'entr£e vers un outil, dans ladite unite de trai- 
tement de donndes, destinSe k la gestion du 
processus de fabrication dudit produit. 

10 

Proc6d6 selon la revendication 1 , dans lequel ledit 
outil destin6 k la gestion du processus de fabrica- 
tion dudit produit est un Syst&me de Gestion et de 
Planification de Projet (MAPPS). 
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